home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000027_rts _Wed Mar 3 22:20:31 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  6KB
  1. Received: from boojum.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA02918; Wed, 3 Mar 1993 22:20:32 MST
  3. Date: Wed, 3 Mar 1993 22:20:31 MST
  4. From: "Rick Snodgrass" <rts>
  5. Message-Id: <199303040520.AA12993@boojum.cs.arizona.edu>
  6. Received: by boojum.cs.arizona.edu; Wed, 3 Mar 1993 22:20:31 MST
  7. To: tsql@cs.arizona.edu
  8. Subject: TSQL Benchmark
  9.  
  10. To the TSQL community:
  11.  
  12. In the past six months or so, several temporal query language
  13. benchmarks have been proposed.  Shashi Gadia has distributed a
  14. document that combines a benchmark of two relations and 14 queries, a
  15. discussion of TempSQL, and the benchmark queries expressed in TempSQL.
  16. Abdullah Tansel in several technical reports has used a benchmark of
  17. 30 queries over a similar schema to evaluate the performance of his
  18. temporal DBMS implementation. And Patrick Kalua and Edward Robertson
  19. in their workshop submission have proposed three semantic benchmarks,
  20. one similar to Shashi's department database and also containing 30
  21. queries.
  22.  
  23. Developing a consensus benchmark that combines all of these efforts
  24. would be very helpful to the community.
  25.  
  26. I propose that everyone interested in the benchmark work together to
  27. assemble a consensus benchmark that could be presented at the workshop
  28. in June.
  29.  
  30. To this end, I have asked Christian Jensen to coordinate this effort.
  31. Christian did an excellent job in coordinating the initial glossary
  32. (and its ongoing successor, which is already of similar size). The
  33. present task will be primarily one of gathering the queries, putting
  34. them into a logical framework, assembling the document (title: "The
  35. TSQL Benchmark"), and in general ensuring that progress is made
  36. towards the goal of completing the benchmark by June. Though Christian
  37. realizes how much effort will ultimately be involved in seeing this to
  38. fruition, he has nevertheless agreed to take on this task.
  39.  
  40. The TSQL Benchmark will differ from first generation benchmarks in
  41. several important aspects. What we need now is a much more
  42. comprehensive approach, starting from first principles.  This approach
  43. will first outline informally the types of queries that can be posed
  44. on the schema. This will allow everyone to attempt to populate the
  45. benchmark to cover all the bases. The TSQL Benchmark will contain many
  46. more queries (perhaps around 100) than any of the first-generation
  47. benchmarks. The benchmark will be independent of any data model, so as
  48. to not favor any specific language proposal. It will also not include
  49. any queries in a specific query language; future documents can present
  50. the benchmark in a particular language, or compare several languages
  51. along the benchmark. The TSQL Benchmark will be in carefully crafted
  52. English, with no other formalisms, to avoid any potential bias.
  53.  
  54. Development can continue on the first generation benchmarks, including
  55. Shashi's.  Indeed, they have much to contribute. As insights are
  56. generated in these benchmarks, it is hoped that they will eventually
  57. migrate into the more comprehensive, consensual benchmark. Shashi
  58. should certainly continue to coordinate development and extension of
  59. his benchmark. Anyone who wishes to participate in either, or both,
  60. is encouraged to do so.
  61.  
  62. Let me also propose a few structuring principles for the TSQL Benchmark.
  63.  
  64. 1. The document will specify a semantic benchmark, with the
  65. objective of comparing the descriptive and operational characteristics
  66. and capabilities of the various models (Patrick and Ed originally
  67. emphasized this distinction). While the benchmark can also be used for
  68. performance comparisons (with more data), that will not be its primary
  69. focus.
  70.  
  71. 2. The benchmark should contain queries that appear reasonable. A
  72. temporal query language should ideally be able to express these
  73. conveniently and naturally.
  74.  
  75. 3. The benchmark should not be considered to constitute a metric for
  76. query language completeness. Such a metric should be based on more
  77. formal notions. On the other hand, the benchmark should be complete in
  78. the sense that it includes as many reasonable queries over the schema
  79. as possible, to ensure that all aspects of query language design are
  80. considered.
  81.  
  82. 4. The benchmark is to be a consensus effort. All researchers,
  83. especially those proposing TSQL language constructs, will be
  84. encouraged to contribute.
  85.  
  86. 5. Everyone who contributes in any significant way will be an author
  87. of this document. Queries will be included if the authors agree that
  88. they are reasonable.
  89.  
  90. 6. The (ambitious) goal will be completion of this benchmark by the
  91. workshop. The benchmark will be used subsequent to the workshop as new
  92. language constructs are proposed.
  93.  
  94. Let me also propose a process to get started with the document.
  95.  
  96. The first decision should be specifying the language functionality
  97. that will be included and, more importantly, the functionality that
  98. will *not* be included in the first draft of the document. Since an
  99. attempt will be made to ensure informal completeness, the scope should
  100. be purposely quite narrow.
  101.  
  102. The next decision will be that of the schema to be adopted. Again, the
  103. scope should be as narrow as possible.
  104.  
  105. Third, a taxonomy of queries over that schema should be developed,
  106. attempting to be maximal to avoid holes.
  107.  
  108. After this basis has been developed and agreed upon, specification of
  109. the actual queries, and population of the example schema with actual
  110. data, can begin.
  111.  
  112. I ask Christian to make strawman proposals for language functionality
  113. and schema, for discussion by the community.
  114.  
  115. This tsql email mailing list will be the medium of discussion.
  116. Schemas/instances/queries can be proposed, discussed, and eventually
  117. incorporated into the document. Christian will periodically make
  118. available draft versions of the document for comment.
  119.  
  120. Given that there already exists a body of some 75 queries (admittedly,
  121. overlapping and somewhat contradictory, but nevertheless available),
  122. it appears that there is sufficient material to begin construction of
  123. a comprehensive benchmark that will be of great help, initially in
  124. comparing language proposals, and eventually in characterizing and
  125. exemplifying temporal databases.
  126.  
  127. Sincerely,
  128.     Rick